Packet-based data networks continue to grow in importance, and it is often desirable to monitor network traffic associated with these packet-based networks on an ongoing basis. To meet these monitoring needs, copies of network packets can be forwarded to diagnostic network monitoring tools. Packets are often forwarded using network hubs, test access ports (TAPs), and/or switched port analyzer (SPAN) ports available on network switches. For example, certain network switches produced by Cisco Systems include SPAN ports to which traffic on the switches are mirrored. It is also noted that other packet monitoring or access methods may also be used to acquire copies of network packets being communicated within a network infrastructure.
To help alleviate the problem of limited access to network packets for monitoring, tool aggregation devices have been developed that allow shared access to the monitored network packets. These tool aggregation devices allow users to obtain packets from one or more network monitoring points (e.g., network hub, TAP, SPAN port, etc.) and to forward them to different monitoring tools. U.S. Pat. No. 8,018,943 and U.S. Pat. No. 8,098,677 describe example embodiments for network tool optimizers that provide solutions for packet filtering and provide, in part, configuration of user-define filters, automatic creation of filter engine forwarding rules, automatic handling of filter overlaps, graphical user interfaces (GUIs) for filter creation, and other features. U.S. Pat. No. 8,018,943 and U.S. Pat. No. 8,098,677 is each hereby incorporated by reference in its entirety.
When a network to be monitored includes a cloud or virtual environment, however, difficulties arise in utilizing prior tool aggregation devices particularly where multiple unrelated users are allocated different cloud resources within the cloud or virtual environment. One such example environment is where resources within a server cloud are offered by a controlling entity (e.g., Amazon Web Services) to different user entities that lease, rent, or otherwise pay for server cloud resources from the controlling entity. If these user entities desire to monitor network activity, the preferred place to conduct such monitoring is often within the network infrastructure for the server cloud. However, as the server cloud is not controlled by or directly accessible to the user entities, this cloud network monitoring is impractical to implement using current tool aggregation devices without the controlling entity opening its network infrastructure to the user entities. Further, the controlling entity of the server cloud typically does not want its network infrastructure or traffic to be visible to the user entities
Even assuming the controlling entity (e.g., Amazon Web Services) is willing to connect a monitoring tool to its server cloud so that copies of packet traffic are forwarded to a monitoring tool (e.g., through a hub, TAP, SPAN port, etc.) desired to be used by a user, these packets will likely include packets for other user entities in addition to the user desiring the network monitoring. This overlap in packet traffic is likely to occur because cloud resources are often virtualized such that processors or cores associated with any particular physical server processing platform (e.g., server blade) may be used by two or more user entities through server instances created within the server processing system platform. Traffic copied from this physical server processing system platform, therefore, will likely include packets that are associated with multiple independent user entities using the different server instances. As such, significant security and confidentiality issues arise if an attempt is made to add network monitoring tools and associated monitoring services to server cloud resources being used and shared by user entities.